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ABSTRACT 


This  report  (1)  identifies  the  features  which  distinguish  SIMSCRIPT 
from  general  programming  languages,  permitting  readers  to  judge  for 
themselves  the  benefits  of  using  SIMSCRIPT  in  their  own  applications; 

(2)  outlines  the  language  and  implementation  differences  between  the  various 
versions  of  SIMSCRIPT;  (3)  specifies  the  resource  requirements  and 
relative  advantages  of  implementing  each  version  of  SIMSCRIPT  at 
MITRE/ESD;  and  (4)  investigates  the  desirability  of  using  SIMSCRIPT  at 
ESD  for  analyzing  problems  related  to  computer  performance. 
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SECTION  I 


INTRODUCTION 


MA  programmer  is  greatly  influenced  by  the  language  in  which 
he  writes  his  programs;  there  is  an  overwhelming  tendency  to  pre¬ 
fer  constructions  which  are  simplest  in  that  language. . ."(1) 

Increasing  demands  have  been  placed  upon  the  Electronic  Systems 
Division  of  USAF  to  provide  support  to  Air  Force  users  in  simulating 
automatic  data  processing  equipment  (ADPE)  systems  performance.  In 
the  past,  these  demands  were  met  with  a  technology  base  that  included 
one  simulation  package  and  considerable  reliance  upon  commercially 
contracted  support  for  its  use.  One  of  the  purposes  of  Project  5720 
is  to  assist  ESD  in  keeping  abreast  of  technology  in  the  ADPE  simu¬ 
lation  area,  and  to  help  provide  this  technology  as  the  needs  dic¬ 
tate. 

(2) 

A  previous  survey  identified  SIMSCRIPT,  which  is  a  computer 
programming  language  oriented  toward  simulation,  as  a  prime  candidate 
for  use  in  ADPE  simulation.  This  report  examines  SIMSCRIPT  in  more 
detail,  both  as  a  general  simulation  tool  useful  to  MITRE/ESD  at 
large,  and  for  its  usefulness  in  ADPE  simulation.  The  particular 
purposes  of  this  report  are: 

(1)  To  identify  the  features  which  distinguish  SIMSCRIPT  from 
general  programming  languages,  permitting  readers  to  judge  for  them¬ 
selves  the  benefits  of  using  SIMSCRIPT  in  their  own  applications. 

(2)  To  outline  the  language  and  implementation  differences 
between  the  various  versions  of  SIMSCRIPT. 

(3)  To  specify  the  resource  requirements  and  relative 
advantages  of  implementing  each  version  of  SIMSCRIPT  at  MITRE/ESD. 

(4)  To  investigate  the  desirability  of  using  SIMSCRIPT  at  ESD 
for  analyzing  problems  related  to  computer  performance. 

It  is  not  possible  to  accomplish  (1)  and  particularly  (2)  above 
without  discussing  SIMSCRIPT  features  at  the  language  level.  Readers 
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unfamiliar  with  programming  may  find  Sections  III  through  V  rather 
incomprehensible  for  that  reason.  In  any  case,  the  SIMSCRIPT  lan¬ 
guage  is  extensive  and  powerful,  and  a  full  appreciation  for  its 
capabilities  cannot  be  acquired  without  making  the  effort  to  learn 
detailed  language  provisions. 

The  remainder  of  this  report  is  organized  as  follows:  Section  II 
outlines  the  historical  development  of  SIMSCRIPT,  Section  III  presents 
the  language  features  which  are  oriented  toward  simulation,  Section  IV 
contrasts  the  language  design  of  SIMSCRIPT  I  with  that  of  SIMSCRIPT  II, 
Section  V  covers  differences  between  all  language  versions  which  result 
from  the  implementation  rather  than  the  language  specification,  and 
Section  VI  offers  some  generalizations  from  preceding  sections  together 
with  considerations  of  efficiency  and  economy  to  reach  conclusions  for 
purposes  (3)  and  (4)  above. 
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SECTION  II 


SIMSCRIPT  DEVELOPMENT 


In  1963,  Harry  Markowitz,  Bernard  Hausner  and  Herbert  Karr  of 
The  RAND  Corporation  published  SIMSCRIPT,  A  Simulation  Programming 
Language,  which  reported  the  design  of  a  language  specifically 
oriented  toward  systems  simulation.  It  was  the  culmination  of  about 
three  years  effort  on  SIMSCRIPT,  plus  previous  design  experience 
with  SPS-1  (Simulation  Programming  System-1)  at  RAND  and  GEMS 
(General  Electric  Manufacturing  Simulator)  by  Markowitz  at  GE. 
Markowitz  acted  as  chairman  of  the  design  team  and  had  ultimate 
responsibility  for  the  logical  design  of  the  system.  Karr  wrote 
the  original  documentation.  The  language  was  implemented  by  Hausner 
for  the  IBM  7040/7090,  through  translating  SIMSCRIPT  program  state¬ 
ments  into  FORTRAN  and  passing  this  text  to  the  FORTRAN  compiler. 

This  implementation  of  the  language  is  now  referred  to  as  SIMSCRIPT  I, 
and  has  become  relatively  obsolete. 

Markowitz  and  Karr  left  RAND  some  time  after  1963  to  set  up 
California  Analysis  Center,  Inc.  (CACI) ,  a  firm  which  markets  a 
version  of  SIMSCRIPT  under  the  nomenclature  1.5  (read  "eye"  point 
five).  SIMSCRIPT  1,5  is  substantially  identical  to  its  predecessor, 
except  that  program  statements  are  assembled  directly  into  machine 
code.  SIMSCRIPT  I  programs  will  therefore  compile  and  execute 
under  the  SIMSCRIPT  1.5  system  as  long  as  they  contain  neither 
FORTRAN  inserts  nor  LOAD,  RECORD,  or  RESTORE  statements. *  SIMSCRIPT 
I,5's  language  differences  therefore  consist  primarily  of  increasing 
the  power  of  and  relaxing  restrictions  for  a  subset  of  instructions. 
SIMSCRIPT  1.5  has  been  implemented  on:  IBM  7040/44,  7090/94,  and 
360,  NCR  200,  CDC  3600/3800,  CDC  6400/6500/6600,  Philco  210/211/212, 
UNIVAC  490/494/1107/1108,  RCA  Spectra  70/45  and  above  and  GE  625/635. 
With  the  exception  of  the  GE  compiler,  which  was  done  by  Digitek,  Inc, 
rather  than  C.A.C.I.,  all  1.5  compilers  are  claimed  to  be  completely 
compatible.  Users  can  therefore  utilize  old  programs  on  new  equip¬ 
ment.  Since  SIMSCRIPT  is  most  frequently  used  for  simulation,  and 
simulation  models  are  seldom  applicable  beyond  the  system  they  were 
designed  to  replicate,  this  transferability  advantage  reduces  to 
one  of  minimizing  phaseover  problems  for  current  simulation  efforts. 

Almost  as  soon  as  work  on  SIMSCRIPT  I  was  completed,  an  effort 
to  produce  an  improved  version  of  the  language  was  initiated. 


These  statements  reference  I/O  operations  and  were  not  considered 
part  of  the  SIMSCRIPT  1.5  language.  They  were,  however,  incorporated 
into  the  SIMSCRIPT  I  language. 
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Markowitz  again  directed  the  design  of  the  language  and  Hausner 
worked  on  the  implementation.  The  language  was  eventually  produced 
in  1968  by  Philip  Kiviat  and  Richard  Villanueva  and  reported  in  a 

RAND  document,  (3)  SIMSCRIPT  II  represents  a  major  departure  from  pre¬ 
vious  versions  since  it  provides  a  truly  general  programming  lan¬ 
guage  that  can  be  used  in  a  wide  variety  of  applications.  The 
features  of  the  language  which  are  oriented  toward  simulation  utilize 
the  same  data  structures  and  event  mechanisms  as  previous  SIMSCRIPT 
versions,  but  the  syntax  and  semantics  utilized  to  specify  these 
constructs  are  significantly  different.  The  nature  and  import  of 
these  differences  will  be  discussed  in  succeeding  sections. 

The  RAND  report  already  referenced,  which  was  also  issued  in 
book  form  by  Prentice  Hall,''*'  j_s  a  very  lucid  exposition  of  a  rather 
difficult  subject,  a  language  that  is  both  rich  (flexible)  and 
powerful.  Unlike  the  SIMSCRIPT  I  documentation,  which  consists  of 
a  single  140  page  volume  organized  in  reference  manual  format,  the 
SIMSCRIPT  II  reports  include  the  text  already  mentioned  (380  pages), ^ 
which  is  designed  as  a  teaching  vehicle,  a  language  reference  manual, 
listing  instruction  syntax,  and  an  implementation  manual^)  which 
identifies  the  interfaces  between  SIMSCRIPT  and  system  hardware  and 
software. 


The  text  is  divided  into  five  chapters  which  are  identified  as 
"levels"  of  the  language  as  follows: (3) 

"Level  1:  A  simple  teaching  language  designed  to  intro¬ 
duce  programming  concepts  to  nonprogrammers . 

Level  2:  A  language  roughly  comparable  in  power  with 
FORTRAN  but  departing  greatly  from  it  in 
specific  features. 

Level  3:  A  language  roughly  comparable  in  power  to 

ALGOL  or  PL/I,  but  again  with  many  specific 
differences. 


Level  4:  That  part  of  SIMSCRIPT  II  that  contains  the 

entity  -  attribute  -  set  features  of  SIMSCRIPT. 
These  features  have  been  updated  and  augmented 
to  provide  a  more  powerful  list  -  processing 
capability.  This  level  also  contains  a  number 
of  new  data  types  and  programming  feacures. 


Level  5:  The  simulation-oriented  part  of  SIMSCRIPT  II 

containing  statements  for  time  advance,  event¬ 
processing,  generation  of  statistical  variates, 
and  accumulation  and  analysis  of  simulation¬ 
generated  data.11 

This  division  into  levels  is  solely  for  expositional  purposes  and 
corresponds  to  no  real  ordering  or  structure  within  the  language  it¬ 
self. 


The  language  was  implemented  at  RAND  for  the  IBM  360/65  under 
version  15/16  of  MVT.  At  the  time  of  program  submission  to  the 
SHARE  library  (1969)  there  were  "no  known  restrictions  on  using  the 
compiler  under  PCP  or  MFT  II,  and  ...  no  known  OS  release  dependen¬ 
cies.”  Unfortunately  time  and  events  proved  otherwise,  and  an 

attempt  by  Villanueva  to  resubmit  the  program  to  SHARE  was  refused,*’ 
since  IBM  no  longer  supports  the  library.  Several  installations  ^ 
have  gotten  SIMSCRIPT  II  running  under  MVT  but  only  recently  (March  1971) 
has  RAND  made  available  a  working  MFT  version.  A  number  of  statements 
defined  for  the  language  were  not  implemented  in  this  version.  Com¬ 
pilation  is  achieved  through  translation  to  assembly  language  and  use 
of  the  IBM  assembler. 

In  1969,  Kiviat  and  Villanueva  left  RAND  to  form  Simulation 
Associates  (S/A)  with  Henry  Kleine,  Arnold  Ockene,  and  later 
Robert  Parente.  The  company  developed  a  faster  version  of  SIMSCRIPT 
II,  that  permits  more  statement  types  than  the  RAND  implementation. 

This  latest  version,  called  SIMSCRIPT  II  Plus,  has  been  marketed  by 
S/A.  Despite  the  technical  excellence  of  the  language  and  its 
implementation,^  Simulation  Associates  ceased  existence  as  a  business 
entity  in  March  1971.  The  assets  of  the  company  have  been  purchased 
by  C.A.C  I.,  who  have  recently  announced  that  they  are  offering 
a  slightly  modified  version  of  II  Plus  under  the  name  SIMSCRIPT  II. 5. 

The  present  status  of  the  languages/implementations  therefore 
is:  (1)  the  SIMSCRIPT  I  language  and  implementation  are  inseparable, 

as  both  were  reported  together,  (2)  1.5  uses  the  language  design 

of  SIMSCRIPT  I,  with  few  modifications,  (3)  the  language  design 
specifications  for  SIMSCRIPT  II  are  reported  in  the  RAND  and  Prentice- 
Hall  publications,  and  (4)  neither  the  RAND  implementation  of 
SIMSCRIPT  II  nor  S/A's  II  Plus  nor  C.A.C.I.'s  II. 5  have  yet  incor¬ 
porated  the  full  repertoire  of  statements  defined  for  the  language. 

2  . 

Apparently  COSMIC  will  now  accept  new  or  revised  programs.  RAND  is 
considering  the  submission  to  SHARE  of  a  revised  version  of  SIMSCRIPT 
II  which  will  operate  under  MFT. 
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Yale,  Princeton,  Columbia,  and  others. 
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For  example,  although  Yale  had  a  working  version  of  the  free 

SIMSCRIPT  II,  they  eventually  purchased  S/A's  implementation. 
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SECTION  III 


SUBSCRIPT'S  SIMULATION  AIDS 


The  intent  of  SIMSCRIPT’s  originators  was  that  the  special  simu¬ 
lation-oriented  features  of  the  language  would  provide  the  mechanisms 
common  to  most  simulation  exercises,  thus  reducing  programming  time 
and  easing  the  modification  of  models.  Since  both  versions  I  and  II 
of  the  language  possess  the  same  data  structures  and  mechanisms  for 
modifying  data  structures  (called  "world  view"),  and  since  it  is 
precisely  these  features  that  distinguish  SIMSCRIPT  from  general  pur¬ 
pose  programming  languages,  a  fairly  brief  identification  of  the 
SIMSCRIPT  world  view  is  provided  below. 


DATA  STRUCTURES 

Every  simulation  model  consists  of  two  prime  components: 

(1)  a  description  of  the  interrelationships  between  system  elements 
that  define  system  state  at  a  point  in  time,  and  (2)  a  specification 
of  the  ways  in  which  system  state  can  change.  In  SIMSCRIPT,  sys¬ 
tem  elements  are  called  "entities."  Entities  are  the  significant 
objects  present  in  the  system  modeled.  For  example,  the  simulation 
of  a  gas  station  would  probably  define  as  entities  the  various 
pumps,  attendants,  and  cars  which  interact  to  produce  the  behavior 
of  interest.  The  description  of  an  entity  is  done  through  associat¬ 
ing  "attributes"  with  it,  whose  values  define  a  particular  configura¬ 
tion  or  state  of  the  entity.  Entities  may  be  "temporary"  i.e.  created 
and/or  destroyed  during  the  simulation,  or  "permanent,"  meaning  just 
that.  The  distinction  between  permanent  and  temporary  entities  is 
made  primarily  for  the  purpose  of  computational  efficiency,  since 
the  same  static  descriptors  and  change  mechanisms  can  be  applied  to 
them.  Entities  can  be  classified  into  sets,  in  which  they  can  be 
ranked  on  FIFO,  LIFO,  or  attribute  value  bases. 

The  means  of  implementing  these  data  structure  constructs  are 
rather  interesting.  Definitional  statements  specify  the  data  struc¬ 
ture  to  the  compiler,  and  core  storage  is  reserved  for  entities  on 
a  dynamic  basis  at  execution  time.  Thus  if  gas  pumps  were  permanent 
entities,  in  the  beginning  of  a  SIMSCRIPT  program,  GAS. PUMP  would  be 
defined  as  a  class  of  permanent  entities  with  specified  attributes 
(e.g.  FLOW. RATE  and  a  STATUS  descriptor).  This  definition  would  set 
up  "pointers"  called  FLOW. RATE  and  STATUS  which  initially  (i.e. 
after  the  program  is  loaded  into  core)  contain  zero.  During  program 
execution  (usually  during  initialization)  a  value  specifying  the 
number  of  gas  pumps  is  read,  a  statement  creating  every  gas  pump 

^FIFO  means  first-in  first-out,  and  LIFO  last-in,  first  out. 
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(reserving  storage)  is  executed,  and  values  are  assigned  to  attributes, 
usually  through  reading  data.  After  this  is  complete,  the  pointers 
FLOW. RATE  and  STATUS  point  to  lists  in  core  where  the  attributes  of 
the  gas  pumps  are  stored.  If  the  number  of  pumps  was  3,  the  struc¬ 
ture  generated  looks  like: 


Once  generated,  the  only  way  to  free  the  core  storage  occupied  by 
permanent  entities  is  to  "destroy"  all  permanent  entities  of  the 
same  type  (e.g.  all  GAS. PUMPs).  A  global  variable  called  GAS. PUMP 
will  be  defined  automatically  by  the  system,  and  it  contains  an 
integer  identifying  the  particular  GAS. PUMP  referenced  last. 

Attendants  would  probably  be  modeled  as  permanent  entities 
also.  Cars  would  be  modeled  as  temporary  entities,  since  they 
enter  the  system  (gas  station),  are  serviced,  and  depart.  Let  CAR 
have  the  attributes  GAS. NEEDED,  ARRIVAL. TIME  and  SERVICE. TIME,  which 
again  are  specified  in  the  beginning  of  the  program  by  a  non-execut¬ 
able  definition.  This  definition  results  in  a  single  pointer,  a 
global  variable  called  CAR  which  initially  contains  a  zero. 

During  the  execution  of  the  program,  the  statements  "CREATE  A 
CAR  CALLED  I"  followed  by  "CREATE  A  CAR  CALLED  J"  produce  the 
following  s tructure: 


CAR  | 
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The  symbol  I  can  be  used  to  reference  a  pointer  to  the  storage 
reserved  for  the  attributes  of  I.  In  order  to  avoid  referencing  of 
temporary  and  permanent  entities  by  name  (e.  g.  I),  global  variables 
are  defined  with  the  same  name  as  the  entity  class.  Thus  "CREATE  A 
CAR"  is  acceptable,  and  equivalent  to  "CREATE  A  CAR  CALLED  CAR". 

The  global  variable  "CAR"  always  points  to  the  most  recently 
referenced  car,  and  is  updated  automatically  when  cars  are  filed 
into  or  removed  from  sets.  Therefore,  reference  to  GAS. NEEDED(J) 
is  equivalent  to  GAS. NEEDED,  as  long  as  the  pointer  in  the  global 
variable  CAR  is  the  same  as  the  pointer  in  J.  Temporary  entities 
can  be  destroyed  one  at  a  time,  and  their  storage  returned  to  free 
storage. 

Sets  are  logical  groupings  of  entities,  and  can  be  used  to 
identify  interrelationships  such  as  queues.  In  the  simple  model 
outlined  here,  each  pump  (assuming  the  layout  warranted  it)  would 
OWN  (have)  its  own  queue.  Although  the  queue  may  typically  have  no 
occupants,  the  data  structure  is  set  up  so-  that  a  potential  queue 
exists  for  each  pump.  The  potential  members  of  each  queue  are  CAR's. 
Defining  every  GAS. PUMP  as  owning  a  queue  automatically  provides 
three  extra  attributes  for  every  pump  created,  called  F. QUEUE, 

L. QUEUE  and  N. QUEUE.  These  are  respectively;  a  pointer  to  the  first 
CAR  in  the  queue,  a  pointer  to  the  last  CAR  in  the  queue,  and  the 
number  of  cars  in  the  queue.  Defining  CAR  as  possibly  belonging  to 
a  queue  automatically  provides  three  extra  attributes  for  each  CAR 
created,  called  P. QUEUE,  S. QUEUE,  and  M. QUEUE,  These  are  respectively; 
a  pointer  to  the  car’s  predecessor  in  the  queue,  a  pointer  to  its 
successor  in  the  queue,  and  a  flag  marking  whether  or  not  it  is 
(1)  or  is  not  (0)  a  member  of  the  queue.  These  set  ownership  and 
membership  attributes  are  the  mechanisms  by  which  sets  are  defined. 

They  link  owners  and  members  together  in  structured  lists,  express- 
ing  all  the  information  concerning  sets  which  is  maintained  by  the 
system.  For  example,  if  the  gas  station  has  three  GAStPUMPs,  num¬ 
bered  1,  2,  and  3,  and  the  number  of  cars  awaiting  service  at  each 
pump  is  0,  1,  and  3  respectively,  then  the  data  structure  generated 
will  be  as  follows: 
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GAS. PUMP  =  3 


Pump  1 
Pump  2 
Pump  3 


P. QUEUE 
S. QUEUE 
M. QUEUE 
GAS. NEEDED 
ARRIVAL. TIME 
SERVICE. TIME 


/ 


For  illustrative  purposes,  the  global  variables  GAS. PUMP  and 
CAR  are  arbitrarily  assumed  to  point  to  the  last  of  each  type  of 
entity  defined  above. 

When  servicing  of  a  car  is  completed,  the  car  next  in  line  for 
servicing  can  be  accessed  simply  by  "REMOVE  THE  FIRST  CAR  FROM  QUEUE". 
This  statement  removes  the  first  car  (CAR2)  from  the  queue  currently 
identified  by  the  implicit  reference  OUEUS (GAS. PUMP)  and  assigns 
the  pointer  to  this  car  to  the  global  variable  CAR.  The  references 
GAS. NEEDED,  GAS . NEEDED (CAR)  and  GAS. NEEDED (CAR2)  are  then  equivalent, 
and  the  first  is  usually  preferred  since  it  can  be  used  to  reference 
the  GAS. NEEDED  by  other  cars  when  CAR  points  to  them.  It  is  therefore 
short,  unambiguous,  and  implicit. 
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SYSTEM  DYNAMICS 


Changes  in  state  of  a  system  are  represented  by  altered  numeri¬ 
cal  value(s)  of  one  or  more  attributes  of  one  or  more  entities  of 
the  system.  Thus  the  removal  of  CAR2  from  the  QUEUE  before  the 
GAS. PUMP  of  the  previous  illustration  results  in  the  following  data 
struc ture: 


Pump  1 
Pump  2 
Pump  3 


P. QUEUE 
S. QUEUE 
M. QUEUE 
GAS. NEEDED 
ARRIVAL.  TIME 
SERVICE.  TIME 


F.  QUEUE 


GAS. PUMP  =  3 
L. QUEUE  N. QUEUE 


FLOW. RATE  STATUS 


Changes  in  system  state,  which  are  accomplished  through  program 
statements  that  alter  attributes,  are  typically  in  event  routines 
supplied  by  the  programmer. 

In  SIMSCRIPT’s  world  view,  the  basic  unit  of  action  is  called 
an  activity.  The  two  important  aspects  of  activities  are  (1)  that 
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they  take  time,  and  (2)  that  they  (potentially)  change  the  state  of 
the  system.  Most  activities  are  bounded  by  two  "events,"  a  start 
activity  event  and  a  stop  activity  event.  Events  take  zero  simulated 
t  ima  and  produce  changes  in  data  structures  which  reflect  the 
change  in  system  state  occurring  at  that  instant  of  time.  The  pas¬ 
sage  of  time  which  occurs  during  an  activity  is  represented  as  a 
time  delay  factor  between  start  and  stop  events. 

Continuing  the  previous  example,  when  a  CAR  b  s  had  its  servic¬ 
ing  completed,  it  will  leave  the  gas  station.  This  action  is 
represented  by  the  destruction  of  the  particular  temporary  entity 
which  represents  the  car  (some  statistical  gathering  may  be  per¬ 
formed  first).  The  STATUS  attributes  of  the  GAS. PUMP  and  the 
ATTENDANT  servicing  the  car  would  be  set  to  zero  to  indicate  that 
they  are  now  idle.  A  test  would  then  be  made  to  see  if  the  QUEUE 
(GAS. PUMP)  had  any  members.  If  so,  conditions  are  established  which 
result  in  the  initiation  of  servicing  for  the  next  car.  This  is  done 
by  "scheduling"  an  event  to  accomplish  these  actions  at  the  current 
time.  Typically,  the  event  which  starts  an  activity  also  schedules 
the  completion  of  the  activity  at  some  future  point  in  time. 

The  occurrence  of  events  in  their  proper  temporal  sequence  is 
accomplished  by  the  SIMSCRIPT  system.  The  mechanisms  employed  are 
an  artificial  system  clock  and  a  timing  routine.  The  changes  in 
system  state  represented  by  an  event  are  accomplished  by  an  event 
routine  which  is  called  by  and  which  returns  to  the  timing  routine. 
The  timing  routine  maintains  a  set  of  all  events  which  are  scheduled 
to  occur,  and  it  calls  event  routines  in  their  proper  order,  up¬ 
dating  the  clock  in  between  as  required.  Thus  a  SIMSCRIPT  simulation 
program  usually  contains  a  small  main  program  consisting  primarily 
of  initialization  statements  which,  in  addition  to  setting  up  data 
structures,  must  schedule  at  least  one  event  before  a  "START  SIMU¬ 
LATION"  statement  is  executed.  This  statement  transfers  control  to 
the  timing  routine,  which  examines  its  set  of  scheduled  events  to 
find  the  earliest,  advances  the  system  clock  to  that  time,  and 
transfers  to  that  event  routine.  If  the  timing  routine  runs  out  of 
events,  it  returns  control  to  the  main  program  at  the  statement 
following  START  SIMULATION. 

This  methodology  is  implemented  through  using  the  data  struc¬ 
tures  defined  earlier.  "Event  notices"  are  actually  temporary 
entities  created  every  time  an  event  is  scheduled.  Event  notices 
are  filed  in  a  timing  set,  which  is  a  set  organized  by  event  type 
and  then  by  scheduled  time  of  occurrence.  If  more  than  one  event 
can  occur  at  the  same  instant  of  time,  the  programmer  can  specify  a 
priority  ordering  between  different  event  types,  as  well  as  break 
ties  within  event  types  (e.g.  servicing  of  two  cars  is  scheduled  to 
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be  completed  at  the  same  instant)  by  high  or  low  values  of  any 
attribute(s) .  Unless  the  programmer  specifies  otherwise,  the  system 
destroys  each  event  notice  before  passing  control  to  the  proper  event 
routine. 
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SECTION  IV 


LANGUAGE  DIFFERENCES  BETWEEN  SIMSCRIPT  I  AND  SIMSCRIPT  II 


As  outlined  in  the  previous  section,  there  are  essentially  two 
distinct  SIMSCRIPT  languages,  I  -  1.5  and  II  -  II  Plus.  1.5  and 
II  Plus  are  derivatives  of  their  predecessors,  constituting  different 
implementations  rather  than  different  languages.  At  present, 
SIMSCRIPT  I  is  relatively  obsolete,  and  the  present  implementations 
of  neither  II  nor  II  Plus  permit  the  full  range  of  statements  identi¬ 
fied  for  the  SIMSCRIPT  II  language.  The  most  useful  means  of 
defining  the  features,  differences*  and  similarities  between  these 
various  versions  of  SIMSCRIPT  is  probably  to  contrast  the  languages 
first,  and  then  to  characterize  those  aspects  which  derive  from  the 
implementations.  The  latter  subject  is  treated  in  the  next  section. 
As  outlined  earlier,  all  versions  of  SIMSCRIPT  provide  the  same 
data  structures  and  event  mechanisms.  The  primary  language  differ¬ 
ences  result  from  the  techniques  by  which  these  features  are  speci¬ 
fied  and  from  augmented  general  programming  power  provided  by 
II  Plus. 


DATA  STRUCTURE  DEFINITION 

In  SIMSCRIPT  I,  all  data  structures  are  specified  on  a  defini¬ 
tion  form  in  a  strict  format  which  requires  precise  card  column 
spacings  for  the  identification  of  temporary  entities,  permanent 
entities,  event  notices,  all  attributes,  and  all  set  memberships. 
Various  entries  on  this  form  are  left  or  right  justified,  according 
to  the  data  type.  Variable  names  of  any  type  are  limited  to  five 
alphanumeric  characters.  Another  form  is  provided  for  initialization 
of  attribute  values,  and  the  meanings  of  the  entries  on  this  form 
are  difficult  to  decipher  because  the  column  spacings  are  exact  and 
its  entries  are  almost  exclusively  numeric. 

In  contrast,  SIMSCRIPT  II  accomplishes  the  same  specification 
of  data  structures  through  free  form  English-like  statements.  First, 
variable  names  are  not  limited  as  to  length,  and  may  include  periods, 
so  that  a  name  like  PART. NUMBER  is  valid  for  any  data  item.  Data 
structures  are  identified  through  a  section  of  the  program  called  a 
PREAMBLE,  which  must  precede  all  other  sections.  Statements  in  this 
section  are  all  definitional,  i.e.  non-executable,  and  serve  to 
identify  variables  which  are  "global"  to  a  simulation  program. 

Global  variables,  like  COMMON  in  FORTRAN,  are  accessible  to  all 
routines  present  in  a  program  (variables  declared  on  the  definition 
form  of  SIMSCRIPT  I  are  global  also).  Entities,  attributes,  and 
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sets  are  specified  through  EVERY  statements,  which  signal  the  com¬ 
piler  that  the  entities  named  possess  the  structure  defined.  In 
terms  of  the  example  of  Section  III,  one  cauld  write: 

PREAMBLE 

TEMPORARY  ENTITIES 

EVERY  CAR  HAS  A  GAS. NEEDED,  AN  ARRIVAL. TIME,  AND  A  SERVICE.  TIME , 
AND  MAY  BELONG  TO  A  QUEUE 

PERMANENT  ENTITIES 

EVERY  GAS. PUMP  HAS  A  FLOW. RATE  AND  A  STATUS  AND  OWNS  A  QUEUE 

EVERY  ATTENDANT  HAS  A  DELAY  AND  A  STATUS 

The  name  following  EVERY  (e.g.  CAR)  is  identified  as  an  entity  of  the 
type  specified  previously  (e.g.  TEMPORARY).  The  attributes  of 
entities  are  denoted  in  a  name  list  following  HAS.  Possible  set 
memberships  are  indicated  following  BELONG(S)  TO,  and  set  ownership(s) 
of  the  name(s)  following  OWNS.  The  set  ownership  and  membership 
attributes  are  automatically  generated  for  each  entity  created.  Un¬ 
like  the  mechanisms  employed  in  SIMSCRIPT  I,  the  above  method  of 
data  definition  is  highly  readable,  helping  significantly  to  produce 
self-documenting  programs.  The  clarity  of  the  structure  of  the  model 
provided  in  SIMSCRIPT  II  aids  significantly  when  that  structure  is 
to  be  altered,  as  is  often  the  case  in  simulation  studies.  One 
author(  7)  "experienced  that  about  75  percent  of  the  debugging  effort 
(with  SIMSCRIPT  1.5)  is  spent  correcting  Definition  and  Initializa¬ 
tion  Forms".  The  free-form  English-like  syntax  of  the  SIMSCRIPT  II 
PREAMBLE  which  replaces  these  forms  facilitates  debugging  through 
making  the  relationships  specified  obvious  even  to  the  casual 
reader.  Some  people  at  the  Aerospace  Corporation  have  used  SIMSCRIPT 
II  PREAMBLE  statements  for  designing  systems  and  communicating  the 
designs,  though  never  intending  to  simulate  the  systems  thus  described. 


EXECUTION  TIME  FACILITIES 

There  are  two  execution- time  aids  to  debugging  in  SIMSCRIPT  II 
which  also  warrant  mention.  A  global  variable  called  BETWEEN. V  is 
defined  by  the  system.  Its  contents,  which  are  initialized  to  zero, 
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are  tested  just  before  the  timing  routine  transfers  to  any  event 
routine.  If  the  programmer  has  altered  BETWEEN, V,  then  the  system 
will  transfer  to  the  routine  named.  For  example,  the  statement 
LET  BETWEEN. V  =  ’TRACE1  sets  the  address  of  the  routine  TRACE  in  the 
contents  of  BETWEEN. V.  Before  each  event  is  executed,  the  programmer 
can  perform  whatever  diagnosis  he  desires  or  collect  statistics 
which  reveal  the  dynamic  properties  of  his  model.  The  steps  taken 
at  this  point  are  determined  by  the  programmer  in  the  routine  TRACE 
(or  any  other  named  routine)  which  he  writes. 

The  second  powerful  debugging  aid  is  achieved  through  defining 
variables  as  "moni tored. "  A  monitored  variable  has  associated  with 
it  both  a  storage  location  and  a  program.  It  therefore  represents 
a  new  data  type,  since  it  has  the  features  of  both  a  function  and 
a  variable.  To  use  the  monitoring  feature,  one  must  explicitly 
declare  a  variable  as  monitored  in  a  DEFINE  statement,  e.g. , 

(a)  DEFINE  X  AS  AN  INTEGER  VARIABLE  MONITORED  ON  THE  RIGHT 

(b)  DEFINE  Y  AS  A  REAL,  2-DIMENSIONAL  ARRAY  MONITORED  ON 
LEFT  AND  RIGHT 

One  must  also  define  right  and/or  left  handed  functions  designed  to 
perform  the  right  and/or  left  monitoring. 

Functions,  e.g.  SIN (A),  are  usually  employed  to  compute  a  value 
from  one  or  more  arguments,  and  can  be  treated  in  expressions  as 
though  they  were  a  variable,  e.g.,  C**2-5*(SIN(A)**3+COS (B) ) .  These 
are  "right-handed”  functions  which  appear  to  the  right  of  an  equals 
sign  and  are  used  to  compute  values.  Left-handed  functions,  on  the 
other  hand,  receive  values.  In  SIMSCRIPT,  it  is  legal  to  say 
LET  FUNCTION* NAME  (I)  =  A,  but  one  must  then  define  a  LEFT  ROUTINE 
FUNCTION. NAME  GIVEN  I.  This  routine  must  include  as  its  first 
executable  statement  ENTER  WITH  X,  which  takes  the  value  of  A  and 
assigns  it  to  X.  From  this  point  on,  the  routine  can  perform  any 
legal  SIMSCRIPT  operations.  The  utility  of  this  construct  becomes 
apparent  when  it  is  used  in  monitoring  variables. 

Suppose  a  programmer  suspects  that  some  problems  with  his 
program  result  from  references  to  a  particular  array.  He  can  then 
specify,  as  in  (b)  above,  that  his  array  Y  is  monitored  on  both  left 
and  right  and  provide  routines  defined  that  way.  This  is  the  only 
change  made  to  his  program.  However,  he  now  has  the  ability  to 
check  every  retrieval  from  storage  (get)  through  a  right  hand  func¬ 
tion 


LET  Z  =  Y (I , J) 
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and  every  assignment  to  storage  (put)  through  a  left  hand  function 

LET  Y(I,J)  =  3*A**2. 


Monitoring  can  be  used  for  checking  for  valid  subscripts,  editing 
data  during  reading,  transformation  of  data  for  printing,  etc.  -- 
whatever  purposes  one  might  wish  to  achieve  every  time  a  storage 
retrieval  or  assignment  is  made.  The  biggest  benefit  with  this 
feature  is  not  that  it  can  be  done  --  one  can  always  insert  a  state¬ 
ment  before  every  put  or  get  which  transfers  to  a  subroutine  --  but 
that  it  is  done  automatically,  without  cluttering  up  a  program  with 
odd-looking  statements.  Thus  if  in  debugging  it  becomes  worthwhile 
to  monitor  a  variable,  the  additions  to  a  program  which  accomplish 
this  are  minimal  and  appear  in  a  few  well-delineated  locations  in  a 
program.  When  the  bug  has  been  discovered  and  eliminated,  the 
monitoring  program  statements  to  be  removed  can  be  located  easily. 

In  contrast,  providing  for  monitoring  a  variable  through  direct 
coding  requires  much  more  work  and  introduces  its  own  opportunities 
for  error  through  overlooking  program  locations  that  either  require 
a  transfer  when  debugging  or  require  the  removal  of  a  transfer  when 
debugging  is  completed. 


LANGUAGE  ADVANTAGES  OF  SIMSCRIPT  II 

Many  of  the  improvements  incorporated  into  SIMSCRIPT  II  represent 
changes  in  more  than  syntax  or  semantics  from  its  predecessor.  A 
partial  survey  of  these  new  features  is  provided  below. 

1 .  Dynamic  Storage  Allocation. 

All  arrays  are  dimensioned  at  execute  time  in  SIMSCRIPT 
II.  In  SIMSCRIPT  I  this  is  true  except  for  local  arrays  (i*e.  arrays 
which  are  not  system  variables,  but  declared  in  a  subroutine),  which 
must  be  dimensioned  as  in  FORTRAN. 

2.  Releasable  Programs. 

All  routines  (subroutines  and  functions)  may  be  declared 
as  RELEASABLE.  In  large  programs  this  feature  permits  discarding  a 
routine  if  it  is  no  longer  required  so  that  its  memory  space  can  be 
used  for  other  purposes.  The  statements  which  initialize  a  simula¬ 
tion  model,  for  example,  are  performed  only  once  in  any  run  unless 
the  model  is  restarted.  These  steps,  which  often  occupy  a  signifi¬ 
cant  amount  of  memory,  can  be  isolated  in  an  initialization  routine 
and  RELEASED  after  they  have  been  performed  to  provide  extra  memory 
during  simulation. 
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3.  Dynamic  Program  Relocation. 

Dynamic  program  relocation,  i.e.  not  only  releasing 
routines  but  later  restoring  them  in  memory  in  operable  form,  is 
defined  in  SIMSCRIPT  II  through  LOAD  and  SAVE  statements.  The  pro¬ 
vision  of  this  facility  greatly  enlarges  the  effective  memory  capa¬ 
city  available  for  program  storage. 

4.  Recursion. 

All  routines  are  recursive  in  SIMSCRIPT  II,  unless 
declared  otherwise.  Hence  the  following  routine,  when  called  once 
by  a  program,  will  return  N  factorial  to  that  program. 

ROUTINE  FOR  FACTORIAL  (N) 

IF  N  =  1,  RETURN  WITH  1 

OTHERWISE  RETURN  WITH  FACTORIAL  (N-1)*N 

END 

5.  Free-Field  Programs. 

SIMSCRIPT  II  statements  may  be  punched  in  any  card 
columns,  and  more  than  one  per  card  is  permissible.  The  only  rules 
which  limit  the  concept  of  a  continuous  program  string  are  imposed 
to  simplify  the  punching  of  comments  and  to  retain  visual  integrity 
of  variables,  e.g.  variable  names  cannot  be  split  between  cards. 

These  features  permit  indenting  statements  to  produce  a  more  readable 
program  and  eliminate  errors  due  to  off-column  punching.  The  only 
word  which  cannot  be  used  as  the  name  for  a  variable  or  label  in  a 
SIMSCRIPT  II  program  is  AND. 

6.  Input/Output 

The  input  of  data  can  proceed  either  under  formatted 
control  or  under  a  free-form  specification  by  which  blank  characters 
mark  the  separation  between  input  fields.  Thus  it  is  possible  to 
say 

READ  X,  Y,  Z 

without  any  FORMAT  statement.  Enough  data  cards  will  be  read  to 
locate  three  values.  A  similar  capability  exists  for  output,  e.g. 
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PRINT  1  LINE  WITH  X,Y,Z  LIKE  THIS 


X  =  ****# *  y  =  **  g  =  ** 

The  free-form  input  capability  listed  above  is  the 
mechanism  which  permits  free-field  SIMSCRIPT  II  programs,  since  the 
compiler  is  written  in  SIMSCRIPT  II.  In  contrast,  SIMSCRIPT  I  I/O 
is  almost  identical  to  FORTRAN,  although  a  report  generator  (RPG) 
capability  is  provided.  SIMSCRIPT  II  offers  no  RPG  facility,  only 
page-heading  statements.  Output  is,  however,  simply  and  straight¬ 
forwardly  achieved. 

7 .  Mode  and  Dimensionality  Specification. 

Unlike  FORTRAN  and  SIMSCRIPT  I,  variables  beginning 
with  I,  J,  K,  L,  M,  and  N  may  be  real  numbers  or  integers  in 
SIMSCRIPT  II.  The  mode  and  dimensionality  of  all  variables  is  set 
implicitly  if  not  declared  explicitly.  The  compilation  process 
initiates  with  background  conditions  which  specify  variable  mode  as 
real  (rather  than  integer) ,  and  dimensionality  as  zero  (rather  than 
1,  or  2,  or  .  .  .).  These  background  conditions  are  overridden  by 
explicit  declaration  (DEFINE  IJK  TO  BE  AN  INTEGER,  1-DIMENSIONAL 
ARRAY)  and  changed  by  specification  (NORMALLY,  MODE  IS  INTEGER, 
DIMENSION  IS  2). 

8.  User  Access  to  System. 

The  programmer  has  complete  access  to  attributes,  con¬ 
stants,  entities,  functions,  routines,  sets,  and  variables  defined 
by  the  SIMSCRIPT  II  system.  Not  all  of  these  are  accessible  in 
SIMSCRIPT  I. 

9.  Storage  References. 

In  SIMSCRIPT  I,  a  different  subroutine  for  storage 
retrieval  (get)  and  assignment  (put)  is  generated  for  every  global 
variable.  Hence  there  are  many  subroutines  and  calls  to  subroutines. 
SIMSCRIPT  II  generates  code  that  can  make  these  references  directly 
through  a  PREAMBLE  generated  control  section  called  PRMB. 

10.  Attribute  Storage 

For  each  group  of  eight  words  required  to  store 
SIMSCRIPT  I  attributes  a  different  block  of  core  storage  is  utilized. 
Hence  storage  referencing  for  entities  with  many  attributes  becomes 
indirect  and  inefficient  relative  to  SIMSCRIPT  II. 
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11.  Event  Scheduling  Priority. 


SIMSCRIPT  I  has  no  provision  for  declaring  priority  of 
occurrence  between  events.  SIMSCRIPT  II  has  the  PRIORITY  (different 
event  types)  and  BREAK  TIES  (by  attribute(s)  for  the  same  event) 
statements  to  accomplish  this  function.  Priorities  among  different 
event  types  are  implicitly  established  in  SIMSCRIPT  I  by  the  order 
of  event  appearance  on  the  Definition  Form.  Thus  a  PRIORITY  is 
provided  by  default;  the  fact  that  it  is  not  explicitly  declared 
does  not  matter  as  long  as  the  implicit  ordering  is  correct.  Signifi¬ 
cant  redesign  of  the  Definition  and  Initialization  Form  entries  may 
be  required  to  alter  priorities,  however. 

12.  OLD  PREAMBLE  Feature. 

Prefacing  PREAMBLE  by  OLD  inhibits  the  production  of 
set  filing  and  removing  routines,  the  timing  routine,  and  LIST 
routines,  and  speeds  the  compilation  process.  A  parallel  capability 
is  available  in  SIMSCRIPT  I,  but  on  a  card-by-card  basis  for  each 
definition  card.  This  is  useful  when  recompiling  due  to  program 
changes  that  do  not  affect  global  variables. 

13.  DEFINE  Word  TO  MEAN  Words. 


This  statement  can  be  employed  as  a  shorthand,  e. g. 
DEFINE  LOCAL  TO  MEAN  DEFINE  I,  J,  K,  L,  M,  and  N 
AS  INTEGER  VARIABLES 

With  this  statement  in  the  PREAMBLE  of  a  program,  the  single  word, 
LOCAL,  in  each  subroutine  defines  I,  J,  K,  L,  M,  and  N  as  integers. 
No  similar  statement  is  provided  in  SIMSCRIPT  I. 
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SECTION  V 


IMPLEMENTATION  DIFFERENCES  -  SIMSCRIPT  I,  1.5,  II,  II  PLUS,  AND  II.  5 


The  fi-ve  versions  of  SIMSCRIPT  can  be  contrasted  in  two  ways: 
through  detailed  variations  in  language  provisions  and  by  differences 
in  more  global  measures  such  as  execution  speed  and  coverage  of 
diagnostics.  These  subjects  are  treated  below  in  the  order  mentioned. 
The  standards  for  language  comparisons  are  the  language  specifications 
for  versions  I  and  II  discussed  in  the  previous  section. 


LANGUAGE  PROVISIONS 

Although  the  language  differences  between  SIMSCRIPT  I  and  1.5 
are  minor,  the  latter  does  provide  for: (  8) 

1.  Local  variables  in  excess  of  five  characters,  e.g. 
THETOTALINVENTORY . 

2.  Symbolic  labels  anywhere  in  columns  2-5.  In  SIMSCRIPT  I 
only  right  adjusted  integers  were  valid. 

3.  Labeled  blank  statements  so  that  labels  can  be  made  equiva¬ 
lent. 

4.  Elimination  of  two  problems  arising  from  the  FORTRAN  integer 
convention. 

5.  Several  other  alterations  which  facilitate  input-output  and 
ease  syntax  restrictions. 

The  RAND  implementation  of  SIMSCRIPT  II  is  consistent  with  the 
language  texts  issued  by  both  RAND  and  Prentice-Hall,  but  a  number 
of  the  statement  types  specified  in  the  design  of  the  language  are 
missing.  These  statements  yet  to  be  implemented  are  outlined  below, 

1.  CLOSE,  ADVANCE,  and  BACKSPACE 

These  commands  affect  the  positioning  of  data  sets.  The 
end-of-file  marker  set  by  a  CLOSE  statement  can  also  be  accomplished 
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through  REWIND,  ADVANCE  and  BACKSPACE  move  the  specified  I/O  device 
forward  or  backward  a  specified  number  of  files  and  can  be  accom¬ 
plished  through  assembly  code. 

2.  Column  Repetition 

This  feature,  provided  in  SIMSCRIPT  I,  permits  large  arrays 
of  data  to  be  printed  with  the  column  indices  (e.g.  1  to  50  on 
page  1  and  51  to  100  on  page  2)  handled  automatically. 

3.  LIST  ATTRIBUTES  OF  EACH  Entity 

Several  forms  of  this  statement  result  in  the  listing,  in  a 
predefined  format,  of  one  or  more  attributes  of  one  or  more  entities. 
It  is  useful  in  debugging,  tracing  dynamic  properties,  etc. 

4.  Automatic  Entity  Checking  When  Entity  Destroyed 

An  execution  error  should  be  flagged  when  an  entity  is 
destroyed  that  is  still  a  member  of  a  set.  Since  the  RAND  SIMSCRIPT 
II  system  does  not  recognize  this  error,  it  could  lead  to  errors 
that  are  difficult  to  debug. 

5.  Left-Handed  Functions 

(Described  previously.) 

6.  Monitored  Variables  and  Attributes 

(Described  previously.) 

7.  All  TEXT  Features 

A  number  of  commands  are  specified  which  permit  the  defini¬ 
tion,  manipulation,  input,  output,  and  mode  conversions  of  character 
strings,  none  of  which  are  presently  available. 

8.  BREAK  TIES 

(Described  previously.) 

9.  Event  Arguments  in  SCHEDULE  and  EVENT  Statements 

The  language  specification  permits  the  syntax  which  follows: 
SCHEDULE  AN  event  GIVEN  expression  list  AT  time  expression.  This 
statement  creates  an  event,  sequentially  assigns  the  attributes 
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listed  in  the  expression  list,  and  files  the  event  in  the  events 
set  ordered  by  its  time  of  occurrence  (time  expression).  The  inability 
to  assign  attributes  in  a  SCHEDULE  statement  requires  only  the 
addition  of  an  assignment  statement.  If  a  BREAK  TIES  ordering  is 
specified,  however,  three  statements  (CREATE,  LET  attributes  * 
values,  and  FILE)  are  required,  since  the  SCHEDULE  statement  does 
the  filing  automatically  with  attribute  values  all  equal  to  zero. 

Thus  the  BREAK  TIES  ordering  can  only  be  maintained  by  assigning 
attribute  values  before  filing  in  the  events  set. 

10.  BEFORE  and  AFTER 

These  statements,  which  appear  in  a  program  PREAMBLE,  are 
helpful  in  debugging.  One  can  use  them  to  direct  the  calling  of 
various  debugging  routines  before  or  after  the  performance  of  certain 
specified  operations.  Thus,  BEFORE  or  AFTER  CREATING  or  DESTROYING 
an  entity,  SCHEDULING  or  CANCELING  an  event,  or  FILING  in  or  REMOVING 
from  a  set,  a  specified  routine  can  be  called.  The  arguments  which 
are  transmitted  to  the  operation  being  monitored  (e.g.  CREATE)  are 
automatically  transmitted  to  the  monitoring  routine. 

11.  ACCUMULATE,  TALLY,  DUMMY,  and  RESET 

ACCUMULATE  and  TALLY  are  statements  which  appear  in  the 
PREAMBLE  of  a  program  which  automatically  generate  a  powerful 
statistics-gathering  capability  for  each  of  the  variables  mentioned 
in  the  statement.  One  can  write; 

ACCUMULATE  AVG.  QUEUE  AS  THE  MEAN  AND  MAX. QUEUE 

AS  THE  MAXIMUM  OF  N. QUEUE 

Every  time  N. QUEUE  changes,  the  appropriate  accumulations 
are  made  so  that  the  variables  AVG. QUEUE  and  MAX. QUEUE  respectively 
contain  the  average  number  of  members  and  the  maximum  number  of  mem¬ 
bers  in  QUEUE.  This  facility  permits  operating  (i.e.  non-PREAMBLE) 
portions  of  programs  to  be  kept  free  of  data  collection  and  data 
reduction  statements.  TALLY  treats  every  observation  value  with 
equal  weight,  e.g.  the  SUM  of  X  while  ACCUMULATE  produces  a 

time-weighted  sum,  e.g.  the  SUM  of  X  =s]£X;jZlti,  where  Atj_  represents 
the  time  duration  of  X^.  Thus  the  value  of  AVG.  QUEUE  above  would 
be  the  time  average  length  of  the  QUEUE.  DUMMY  simply  reduces  the 
storage  allocation  used  for  these  purposes  when  possible.  RESET 
restores  the  statistical  counters  employed  to  zero. 
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12.  RANDOM  Variables 


This  provision  permits  the  random  sampling  from  an  arbitrary 
distribution  defined  by  the  programmer.  This  is  accomplished  through 
storing  a  table  containing  a  description  of  the  cumulative  distribu¬ 
tion  function.  The  concept  and  effect  are  equivalent  to  FUNCTION 
blocks  with  random  number  seeds  in  GPSS.  Variables  may  be  defined  as 
step  (discontinuous)  or  linear  (continuous)  functions,  as  in  GPSS. 

13.  ORIGIN  .R 

This  is  a  routine  which  permits  the  specification  of  time 
in  a  calendar  format  (e.g.  3/24/71  09  45  represents  9:45  in  the  morn¬ 
ing  of  March  24,  1971)  through  establishing  a  time  origin  against 
which  such  calendar  specifications  can  be  matched. 

SIMSCRIPT  II  Plus  does  not  yet  include  the  entire  repertoire  of 
language  statements  defined  for  the  SIMSCRIPT  II  language.  The  fol¬ 
lowing  statements,  which  have  not  been  implemented,  have  been  discussed 
previously . 

1.  CLOSE,  ADVANCE,  BACKSPACE 

2.  Column  Repetition 

3 .  SAVE ,  LOAD 

4.  TEXT  features 

5.  ACCUMULATE,  TALLY,  DUMMY,  and  RESET 

6.  ORIGIN. R  routine 

Simulation  Associates  had  planned  to  implement  some  of  these 
statements  this  year,  but  C.A.C.I.'s  time  schedule  nay  be  quite  different. 

Several  additions  and  alterations  to  the  defined  SIMSCRIPT  II 
language  have  been  incorporated  in  II  Plus.  These  are: 

1.  Routines  no  longer  have  to  be  declared  as  RELEASABLE.  The 
programmer  can  simply  write  RELEASE  routine  name. 

2.  The  standard  TRACE  output  routine  called  by  the  run-time 
error  monitor  now  calls  a  routine  named  SNAP.R.  SNAP.R  is  present 
as  a  null  routine  in  the  run-time  library,  i.e.  as  ROUTINE  SNAP.R 
RETURN  END,  but  may  be  replaced  by  the  user's  own  SNAP.R  routine. 

Hence,  important  data  items  can  be  printed  whenever  execution  errors 
are  encountered. 
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In  its  announcement  of  SIMSCRIPT  II.  5,  C.A.  C.I.  has  thus  far 
identified  only  one  significant  change  from  II  Plus,  the  provision 
of  double '-precision  floating-point  arithmetic.  Evidently,  in  some 
simulation  applications  a  loss  of  numeric  significance  has  resulted 
from  the  use  of  single-precision  floating-point.  This  addition  is 
currently  being  implemented,  and  others  are  expected  to  follow. 


NON-LANGUAGE  FEATURES 

Other  important  differences  between  the  various  versions  of 
SIMSCRIPT  derive  from  features  other  than  the  language  available  to 
the  programmer.  Among  these  are  diagnostics  for  error  correction, 
typical  core  storage  requirements,  and  speed  in  compilation  and 
execution. 

1.  Diagnostics 

The  two  recent  SIMSCRIPT  implementations,  II  and  II  Plus, 
provide  a  fairly  extensive  set  of  diagnostics  during  both  compilation 
and  execution.  In  contrast,  I.5’s  diagnostics  are  rather  minimal, 
as  can  be  seen  below. 


Table  I 

Number  of  Error  Diagnostics 
SIMSCRIPT  1.5,  II,  and  II  Plus 


SIMSCRIPT 

Number  of  Messages 

Provided  During 

Version 

Compilation 

Execution 

1.5 

29 

0 

II 

79 

105 

II  Plus 

86 

107 

Another  feature  of  SIMSCRIPT  II  and  II  Plus  is  that  the  compiler 
"corrects"  as  many  errors  as  it  can  and  ignores  statements  contain¬ 
ing  the  remainder.  Thus,  when  a  significant  number  of  programmer 
syntax  errors  can  be  corrected  appropriately,  a  run  is  not  lost. 

This  correct  or  ignore  feature  is  used  to  force  the  execution  of 
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every  program  except  those  with  syntax  error(s)  in  the  PREAMBLE 
section  that  are  likely  to  invalidate  all  subsequent  routines.  The 
philosophy  behind  this  is  that  valuable  information  is  gained  through 
executing  as  far  as  possible.  In  contrast,  I  and  1.5  stop  upon 
encountering  an  error  in  the  Initial  Conditions  Data  Deck.  It  may 
take  several  runs  to  discover  all  errors  present  in  this  deck. 

2.  Core  Storage  Requirements 

Both  II  and  II  Plus  normally  require  150K  bytes  to  compile 
using  a  compiler  overlay,  180K  bytes  without  the  overlay,  and  52K 
bytes  to  execute  simulation  models.  Although  comparable  figures  for 
1.5  are  not  available,  SIMSCRIPT  I  was  implemented  in  a  32K  word 
machine  (36  bits/word).  Promotional  material  distributed  by 
Simulation  Associates  claims  that  II  Plus  generates  smaller  programs 
making  better  use  of  available  core  than  SIMSCRIPT  I  or  1.5. 


3.  Compilation  and  Execution  Speed 


There  is  little  doubt  that  the  II  Plus  implementation  com¬ 
piles  programs  faster  than  SIMSCRIPT  II.  The  range  of  estimates 
available  suggest  that  II  Plus  compilation  takes  roughly  half  as 
much  time,  due  largely  to  the  fact  that  the  RAND  version  uses  IBM's 
assembler,  and  the  II  Plus  version  utilizes  a  subset  of  the  IBM  com- 
piler  written  by  Simulation  Associates.  Robert  Parente  suggests 
that  completing  a  large  simulation  study  would  cost  three  times  as 
much  with  the  SHARE  version  as  with  II  Plus.  At  present,  rough 
estimates  for  II  Plus'  are  compilation  speed  of  500-1000  cards  per 
minute  (depending  upon  statement  mix)  and  execution  speed  of  about 
one  millisecond  per  statement.  For  comparison,  GPSS  executes  about 
1  block  per  millisecond.  The  clients  of  Simulation  Associates  have 
expressed  more  concern  with  compilation  speed  than  execution  speed. 


Simulation  Associates  distributed  a  performance  comparison 
between  SIMSCRIPT  1.5  version  1.0  and  SIMSCRIPT  II  Plus  Release  2A. 
Their  data  are  displayed  in  Table  II,  which  shows  that  II  Plus  is 
somewhat  more  demanding  of  space  and  time  during  compilation  than 
1.5,  but  very  much  more  efficient  during  assembly.  The  II  Plus  data 
and  Mr.  Parente' s  estimate  are  inconsistent,  but  recent  changes  to 
the  compiler  have  improved  its  speed,  so  that  the  Table  2  figures 
may  be  slightly  out  of  date. 


^  Formerly  of  Simulation  Associates. 
'  Given  by  Robert  Parente. 
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Table  II 


SIMSCRIPT  1.5  and  II  Plus  Performance  Comparisons 

Job  Shop  Simulation  Model 
(360/65  Timings) 


Characteristic 

SIMSCRIPT  I. 

5  SIMSCRIPT  II  Plus 

Source  Statements 

115 

105 

Data  Cards 

63 

9 

CPU  Seconds 

-  Compilation 

16.2 

13.4 

18.  2* 

-  Assembly 

14.4 

2.  5 

3.6* 

-  Execution 

.6 

.4 

-  Total 

31.  2 

16.  3 

22.  2* 

CPU  Milliseconds/Source  Statement 

-  Compilation 

140.  9 

127. 6 

173. 3* 

-  Assembly 

125.  2 

23.8 

34.3* 

-  Execution 

5.2 

3.8 

-  Total 

271.  3 

155.2 

211.4* 

Core  Required  (Thousands  of 

Bytes) 

-  Compilation 

108 

146 

-  Assembly 

104 

60 

-  Execution 

84 

42 

*Figures  are  for  initial  compilation  of  entire  program.  Preceding 
figure  is  for  compilation  of  all  programs  using  OLD  PREAMBLE  feature. 
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One  reason  why  II  Plus  execution  is  faster  than  1.5  stems 
from  its  efficiency  in  dynamic  storage  allocation.  With  1.5,  garbage 
collection  was  nearly  continuous.  II  Plus  keeps  lists  (actually 
SIMSCRIPT  sets)  of  identical  segments  of  free  core.  For  example, 
the  temporary  entity  CAR  and  the  event  notice  ARRIVAL  may  each  require 
6  words  of  core.  When  one  of  these  is  destroyed  or  cancelled,  its 
former  record  (slot  in  core)  is  put  into  the  set  of  all  6-word  records 
that  have  been  returned  to  free  storage  and  that  are  currently  un¬ 
used.  When  one  of  these  6-word  records  is  created,  the  procedure  is: 

(1)  Check  the  6-word  set  to  see  if  any  available.  If  so,  take 
the  first,  if  not, 

(2)  Go  to  the  next  larger  list  and  try  there.  If  unsuccessful, 

(3)  Use  GET  MAIN  of  0/S  360.  If  unsuccessful, 

v4)  Try  garbage  collection  until  enough  space  is  provided.  If 
impossible , 

(5)  Flag  an  error. 

An  extension  of  SIMSCRIPT  II,  called  the  Extendable  Com¬ 
puter  System  Simulator  (ECSS)  has  been  developed  at  RAND.  It 
permits  simulations  with  a  process  orientation,  and  contains 
SIMSCRIPT  II  as  a  language  subset.  Although  it  is  still  in  a  field 
test  status,  when  operational  it  could  provide  a  powerful  tool  for 
computer  systems  simulation.  Thus  its  existence  is  a  cogent  argu¬ 
ment  in  favor  of  SIMSCRIPT  II  or  II. 5  rather  than  1.5. 
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SECTION  VI 


CONCLUSIONS 


The  data  structures  and  event  mechanisms  provided  in  SIMSCRIPT, 
together  with  the  flexibility  and  power  of  the  language,  permit  the 
modeling  of  complex  systems  with  both  brevity  and  clarity.  Reviews 8 
of  simulation  languages  generally  consider  SIMSCRIPT  to  be  one  of 
the  most  powerful  of  the  simulation  languages  currently  available. 
This  is  only  one  of  the  criteria  by  which  a  language  should  be  selec¬ 
ted,  however.  Others  are  listed  below. 


CRITERIA  FOR  LANGUAGE  SELECTION 

The  reasons  cited  for  selecting  one  computer  language  instead 
of  another  include: 

(a)  Programming  concepts, 

(b)  Usability, 

(c)  Readability, 

(d)  Training  required, 

(e)  Cost, 

(f)  Flexibility, 

(g)  Documentation, 

(h)  Support, 

(i)  Modeling  concepts  and 

( j)  Transferability 

SIMSCRIPT,  particularly  II  Plus,  provides  extensive  language  level 
advantages,  well-designed  programming  concepts,  modeling  constructs 
and  programming  flexibility  that  permit  natural  system  descriptions 
and  highly  readable,  self-documenting  programs,  and  reasonable  sup¬ 
port  and  documentation.  On  the  negative  side,  when  compared  to  more 


8 


See  References 


9-15. 
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structured  languages  like  GPSS,  SIMSCRIPT  is  more  difficult  to  learn 
and  debug,  and  takes  longer  to  code.  If  many  replications  of  a  par¬ 
ticular  simulation  experiment  are  to  be  done  for  statistical  validity, 
and  if  many  experiments  are  involved,  then  the  more  efficient  code 
generated  by  SIMSCRIPT  will  be  preferable  to  the  interpretive  opera¬ 
tion  of  GPSS.  However,  if  the  rapid  production  of  a  small  number  of 
runs  is  emphasized,  then  GPSS  should  be  used. 

Although  the  reasons  cited  can  and  do  influence  language  selec¬ 
tion,  the  actual  decision  process  on  a  case-by-case  basis  often 
reduces  to  a  consideration  of  (1)  the  programmer's  capability  and 
(2)  availability  of  the  system  at  your  installation.  Language  selec¬ 
tion  decisions  therefore  frequently  produce  non-optimal  overall 
results.  Given  a  limited  simulation  task  today,  one  would  doubtless 
select  GPSS  (if  available  at  the  installation  and  known  to  the  pro¬ 
grammer).  Every  time  in  the  future  that  the  same  situation  arises, 
the  decision  would  be  the  same;  but  if  a  "joint"  decision  considering 
all  of  this  work  could  be  made,  the  language  selected  might  well  be 
other  than  GPSS,  i.e.  an  investment  in  language  availability  and 
programmer  knowledge  might  be  warranted.  There  is  no  escape  from 
imperfect  foresight,  but  one  may  as  well  make  best-guess  projections 
of  future  requirements  and  incorporate  these  projections  into  the 
decision-making  process.  A  review  of  past  and  projected  future 
simulation  efforts  may  prove  worthwhile  from  this  standpoint. 


VERSIONS  OF  SIMSCRIPT 

Three  versions  of  SIMSCRIPT  are  presently  candidates  for  utili¬ 
zation:  1.5,  II,  and  II  Plus-II.  5.  Although  II  is  free,  it  is  not 
supported,  is  significantly  slower  than  II  Plus,  and  only  recently 
has  become  operative  under  MFT.  An  installation  might  economically 
use  SIMSCRIPT  II  for  limited  applications,  or  as  a  test  to  determine 
programmer  acceptance  and  utilization.  Once  utilization  of  SIMSCRIPT 
II  passes  a  certain  threshold,  however,  it  will  be  less  expensive 
to  buy  II  Plus. 

Although  the  present  status  of  II  Plus-II. 5  is  somewhat  evolu¬ 
tionary,  it  already  offers  many  advantages  over  1.5.  Its  only 
disadvantage  is  cost,  although  cost  comparisons  are  muddied  by  a 
dissimilarity  in  quoted  price  terms.  C. A. C. I.  of fers  1.5  on  the 
following  bases:  (a)  two  year  lease  for  $12,400,  including  system 
maintenance  and  updating,  with  subsequent  years  on  a  yearly  basis 
for  $3,000,  (b)  perpetual  usage  for  $15,000,  including  two  years 
of  system  maintenance  and  updating,  with  subsequent  years  for  $1,500, 
(c)  one  year  lease  for  $7,200,  including  system  maintenance  and 
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updating,  with  a  second  year  at  $7,200  and  the  third  and  succeeding 
years  for  $3,000.  C.A.C.I.  now  offers  II. 5  for  a  flat  $500/month, 
although  optional  pricing  arrangements  may  be  offered  in  the  future. 
For  a  five  year  period,  the  minimum  1.5  cost  would  therefore  be 
$19,500,  while  II. 5  would  cost  $30,000.  If  the  simulation  efforts 
involved  are  large  and  time-consuming,  the  faster  operation  of  II. 5 
may  well  result  in  its  being  the  most  economical.  It  also  offers 
the  many  programmer  advantages  detailed  earlier.  In  the  opinion  of 
John  Maguire,  who  as  Senior  Vice  President  and  Director  of  Technical 
Operations  for  C.A.C.I.  speaks  as  the  vendor  of  both  versions, 
although  1.5  is  presently  used  in  far  more  installations  than  II  or 
II.  5,  and  although  II. 5  is  still  in  a  state  of  flux  as  additional 
statements  are  implemented  and  the  compiler  is  speeded  up,  in  five 
years  more  people  will  be  using  II . 5  than  1.5. 

SIMULATION  OF  COMPUTER  SYSTEMS 

Developing  a  valid  model  of  a  computer  system  requires:  (1) 
expertise  in  the  techniques  of  simulation,  including  knowledge  of 
both  statistics  and  the  computer  simulation  language  employed,  (2) 
appreciation  for  the  inner  workings  of  system  software  and  its  points 
of  interaction  with  applications  programs  and  service  routines,  (3) 
knowledge  of  hardware  architecture,  interactions,  and  timings,  and 
(4)  sufficient  data  concerning  applications  programs  to  generate 
valid  workload  models.  The  effort  required  is  large,  and  the  talents 
demanded  diverse.  The  specification,  design,  coding,  debugging, 
statistics  gathering  and  reduction,  and  finally  the  validation  of 
the  simulation  model  cannot  be  accomplished  in  short  periods  of 
time.  For  these  reasons,  simulation  is  a  questionable  tool  for 
evaluating  vendor  proposals  tendered  in  a  normal  procurement  cycle, 
regardless  of  the  language  used. 

Simulation  can  be  employed,  however,  when  the  time  and  resources 
are  available,  as  is  often  the  case  during  system  design.  Examples 
of  this  are  readily  available  -  -  the  GPSS  simulation  of  the  Advanced 
Airborne  Command  Post  and  many  computer  manufacturers'  simulations 
of  hardware  and/or  operating  systems.  The  utility  of  SIMSCRIPT  to 
ESD  would  appear  to  be  in  future  design  and  feasibility  studies  in 
which  the  time  and  resources  are  available  and  in  the  many  sub¬ 
sidiary  problems  which  arise  that  do  not  require  the  modeling  of  a 
complete  computer  system. 


The  decision  to  provide  SIMSCRIPT  as  a  simulation  tool  at  MITRE / 
ESD  hinges  primarily  upon  expectations  concerning  the  size  and 
character  of  future  simulation  efforts.  SIMSCRIPT  requires  more 
investment  than  many  of  its  competitors  (particularly  CPSS)  but  is 


,0 


capable  of  producing  better  results.  To  do  so  requires  a  higher 
level  of  programmer  expertise,  at  least  for  simple  models.  The 
coding  of  complex  models  in  GPSS  can  become  quite  involved  if  the 
language  (block)  constructs  do  not  identify  easily  with  system  elements. 
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